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METHOD AND APPARATUS FOR INTERNET-BASED ACTIVITY 

MANAGEMENT 

5 

This application claims the benefit of U.S. Provisional Patent Application No. 
60/139,816 filed June 21, 1999. The entire disclosure of that application, including the 
appendices thereto, is incorporated by reference herein. 

10 BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The invention relates in general to software and hardware for management of 
15 activities, and in particular to novel systems and methods for managing activities which 
use the internet as a transport and which facilitate access by a broad user base. 

2. Related Art 

20 Activities that involve a number of people, not all co-located, repeatedly 

cooperating to achieve a common goal are notoriously hard to manage. One such 
activity is the provision of evidence-based medical treatment to patients. The provision 
of evidence-based medical treatment involves a number of care providers and patients, 
not all co-located, who repeatedly cooperate to operationalize, always under slightly 

25 different circumstances, a set of treatment guidelines appropriate to each patient. 

Management of the provision of evidence-based medical treatment for 
chronically ill patients has, heretofore, generally been done manually. Such care 
typically spans a long period of time, and requires the involvement of a number of care 
30 providers: physicians, nurse practitioners, specialists, test laboratories, pharmacies, 
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etc. Once a diagnosis for an illness has been made, a physician generally prescribes 
treatment by marking on a paper chart, or writing a note to an assistant. There are 
several steps involved in following up with the treatment, such as ordering lab tests, 
reviewing results, ordering additional tests, prescribing medications, checking the 
5 results of medications, scheduling additional visits, providing educational material. 
These tasks can multiply significantly when a number of patients with different 
illnesses are involved. 

When prior art methods are used, substantial time can be wasted in keeping 
10 track of what needs to be done for whom. There is no consistent method of 
communicating between the various care providers. Information can be misinterpreted, 
a note could be misplaced or lost, resulting in inappropriate care or no care, which 
could be costly. 

15 In prior art systems for care management, the treatment plan for a patient 

usually consists of a paper with a high level prescription or a list of common tasks or 
responses to be carried out. The information is typically vague and not specific to a 
patient's specific, changing medical conditions. Prior art systems lack an automated 
process for selecting the right set of care options and associated tasks, and assigning 

20 them to a patient based on the patient's specific condition. As a result, it is not 
possible to effectively and efficiently create a treatment plan specific to each individual 
patient, and share it with all the care providers. The care treatment plan documentation 
that exists is generally in the form of a flat document listing all possible treatment 
variations. It is difficult to create, act upon and manage a patient treatment plan from 

25 such a flat document in each instance. 

Evaluation of next steps has been based upon additional paper-based 
information, which may not be up-to-date or accurate. To properly prescribe the next 
treatment option, information from several sources, including the patient, needs to be 

2 
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collected and evaluated. Previously, such information was collected from patients and 
other providers via telephone, personal visits, or paper. This collection process is time- 
consuming, and inconsistent, which delays the treatment. 

5 

OBJECTS AND SUMMARY OF THE INVENTION 

It is therefore an object of the invention to provide an improved system and 
method for activity management. 

10 

It is a further object of the invention to provide an improved system for 
managing evidence-based medical treatment services. 

In accordance with the invention in its preferred embodiment, a set of software 
15 applications are provided which operate in combination with hardware and use the 
internet as a transport to manage medical treatment services. Tasks involved in 
treating a patient are coordinated by assigning a care treatment plan to each patient. 
Patient information is first collected from patients, care providers, and other sources. 
The software then "permits a cooperating group to select and create a care treatment 
20 plan from a hierarchical treatment plan template library consisting of a large collection 
of care plan templates, each specific to a particular illness type or subtype. Each care 
plan template consists of a different combination of care options. Each care option 
consists of a different combination of tasks (e.g., Office Visit, EKG, blood test, 
medication, etc.). By selecting an appropriate care plan template and selecting 
25 appropriate care options within that template, a care plan (i.e. a collection of tasks) 
specific to the patient's situation can be created which sets forth the care options that 
typically need to be performed, when those tasks need to be performed, and by whom, 
to achieve each goal variant. 
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The software in its preferred embodiment provides a management system which 
permits individuals within the cooperating group to further specify, in very little time, 
the activity template and activity instances therein so that they are aligned with a goal 
5 variant. While an activity is being performed, tasks whose relevance to the goal 
variant could not be predetermined can be dynamically evaluated to determine whether 
or not they need to be performed. Specific care options and tasks for further 
treatment can be dependent on the results of prior tests or examinations, or additional 
information collected from various sources. The software application includes a 
10 template instantiation and transaction engine which is able to simultaneously manage 
the activity templates for thousands of activity instances. 

Access to the system by users is preferably provided via a web browser. In this 
respect, members of the cooperating group have access to the software application no 
15 matter where they are - without any special infrastructure requirements. Access to the 
system by each member of the cooperating group can be limited to those pieces of 
information (e.g., tasks) that are relevant to that member. 

20 BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, features, and advantages of the invention will 
be apparent from the following more particular description of preferred embodiments 
as illustrated in the accompanying drawings, in which reference characters refer to the 
25 same parts throughout the various views. The drawings are not necessarily to scale, 
emphasis instead being placed upon illustrating principles of the invention. 

FIG. 1 is a diagram illustrating a hierarchical task list in accordance with a 
preferred embodiment of the invention. 
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FIG. 2 shows a diagram illustrating the automatic task scheduling feature of the 
invention in accordance with a preferred embodiment. 

FIG. 3 shows a diagram illustrating the preferred system and method of the 
invention for collecting relevant clinical information from geographically distributed 
multiple participants in an asynchronous manner, using conditional questionnaires over 
the internet. 

FIG. 4 shows a block diagram illustrating the architecture of the system through 
which the invention is delivered according to a preferred embodiment. 

FIG. 5 shows a block diagram illustrating the flow of data among the 
components of the system of the invention. 

FIG. 6 shows a block diagram illustrating the flow of data among the 
components of the system of the invention in connection with an XML request. 

FIG. 7 shows a diagram illustrating two ODC objects and their relationships. 

FIG. 8 shows a diagram illustrating the ODC driver's relation to ODC 
Elements. 

FIGS. 9-13 show screenshots illustrating the user interface in the preferred 
embodiment of the "CareCentraT software of the invention. 

FIGS. 14-19 show screenshots illustrating the user interface in the preferred 
embodiment of the "Customizer" software of the invention. 
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DETAILED DESCRIPTION 

5 

The invention in its preferred embodiment provides a system for managing 
evidence-based medical treatment services. For example, a breast cancer management 
system can be provided using the invention. In the context of such a system, the 
10 invention can be used to manage the care of patients who need to undergo a number of 
procedures to determine whether or not they have breast cancer and to manage the 
treatment of patients who have been diagnosed with breast cancer. In both cases, the 
invention preferably provides functionality: 

• to collect from everyone involved in the care of the patient, including the patient 
15 himself, just the information that care providers need in order to determine the 

patient's state, 

• to enable the activities and tasks that need to be performed to be continually refined 
in order that the patient can continue to be treated appropriately, 

• to enable everyone who is responsible for performing tasks, no matter where they 
20 are, to be reminded when each task needs to be performed, 

• to enable everyone who is responsible for performing tasks, no matter where they 
are, to get substantial automated assistance in performing the tasks, 

• to enable the efficacy of each of the actions and tasks - for a particular population 
of patients — to be evaluated, 

25 • to enable the templates that define what actions, tasks, and question sets are 
appropriate in what circumstances to be modified by the user organization based on 
the results of the efficacy evaluations. 
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The invention preferably uses the internet, or a secure, virtual private network 
within the internet, as a data transport. Alternative embodiments may use other types 
of private wide area networks, such as an intranet or an extranet, without departing 
from the spirit and scope of the invention. 

5 

The invention in its preferred embodiment comprises two software artifacts, 
which are respectively referred to herein as the Customizer and CareCentral. The 
Customizer enables the members of a cooperating group to create activity templates; 
these templates identify possible activity options and, for each option, specify what 
10 tasks need to be performed and what information needs to be collected in order for the 
activity (and its management) to be accomplished. 

CareCentral, which is accessed via a user's web browser, enables a member of the 
cooperating group involved in a particular activity instance to further specify, in a few 

15 seconds, which activity options need to be performed to achieve the goal implied by 
that instance. CareCentral monitors the situation and, based on all of the information it 
has been provided with to date, dynamically evaluates whether or not certain 
conditional actions specific to this activity instance are required. CareCentral' s 
template instantiation and transaction engine is able to simultaneously manage the 

20 activity templates for thousands of activity instances. 

FIG. 1 is a diagram illustrating a hierarchical task list in accordance with a 
preferred embodiment of the invention. The Customizer tool is used to generate a 
hierarchical task list comprising the tasks always implied for any patient with a 
25 particular problem, and also the tasks that may be implied depending on the patient's 
particular situation. Since a "flat" collection of tasks can be difficult to manage, an 
activity template is created which consists of a hierarchy of tasks that are distributed 
across multiple Care Plan Templates (CT) related to different clinical conditions. Each 
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care template consists of multiple Care Options (CO). Each care option consists of 
multiple Tasks (T). 

Each care option and task can have a "YES", a "NO" or a "MAYBE" state of 
5 specification. Based on the clinical condition, certain care options and certain tasks 
will have an automatic "YES" state specified. Based on the patient's observed 
condition, relevant care options and tasks with "MAYBE" conditions can be switched 
to "YES" or "NO". This method allows only the tasks relevant to a patient's 
particular state to be identified for performance. 

10 

FIG. 2 shows a diagram illustrating the automatic task scheduling software 
feature of the invention in accordance with a preferred embodiment. This feature 
provides for automatically scheduling tasks that are not normally implied, i.e., set to 
"YES." Such tasks are automatically added to a task hierarchy instantiation by 
15 applying the relevant set of rules to information collected about the patient's particular 
situation. 

To accomplish automatic task scheduling, a set of "rules" are first specified 
within each care plan and care option in a hierarchy to examine relevant information 
20 identified as information objects, II, 12... .In, collected from multiple sources: 
interactive questionnaires, external databases etc. When conditions specified for a rule 
are satisfied, a care option set to "YES" or a task set to "YES" is automatically added 
to the task hierarchy instantiation. This method allows only the tasks relevant to a 
patient's particular state to be automatically identified for performance. 

25 

FIG. 3 shows a diagram illustrating the preferred system and method of the 
invention for collecting relevant clinical information from geographically distributed 
multiple participants in an asynchronous manner, using conditional questionnaires over 
the internet. The population of personnel involved in the medical treatment of a 

8 
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patient is usually geographically dispersed. This system and method provides a means 
for asking a group of geographically distributed participants a set of questions which 
are relevant to a particular participant's particular situation, and gathering the resulting 
information to enable the automatic scheduling of hierarchical tasks. 

5 

The internet is preferably used to present to each participant (including the 
patient) a questionnaire consisting of multiple questions related to a patient's particular 
situation. The questions are conditioned such that only the relevant questions are 
displayed, based on the answers received to previous questions. Questions not relevant 
10 are hidden from view. 

This mechanism allows only the relevant information to be collected from a 
wide variety of sources. The information can be collected in an asynchronous fashion, 
whenever it is needed, or whenever the participant can provide it, in a manner whereby 
15 timing is not critical. Participants may provide information from wherever they are - 
from geographically distributed locations. The information collected is then used by 
the automatic task scheduling software discussed above. The rules associated with 
automatic task scheduling are applied to the information to automatically schedule 
relevant tasks for a particular patient. 

20 

SYSTEM ARCHITECTURE OF THE PREFERRED EMBODIMENT 

The system architecture in accordance with a preferred embodiment of the invention 
25 is described below. It will be apparent to those skilled in the art that other 
architectures are possible without departing from the spirit and scope of the invention. 
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Reference is now made to FIG. 4, which shows a block diagram illustrating the 
architecture of system through which the invention is delivered according to a preferred 
embodiment. The architecture includes a client, presentation services, application 
services, data services, and databases. Each of these elements is described below. 

5 

The client preferably comprises a DOM-compliant web browser or Internet 
Explorer 4, but may comprise another suitable web browser. The presentation services 
portion of the architecture preferably includes a web server supporting Active Server 
Pages along with a web presentation layer. Active Server Pages are used to allow 

10 efficient dynamic generation of web pages. Because both the content and the layout of 
web pages are data driven in CareCentral, this efficient dynamic generation of web 
pages provides significant advantages. For example, by using Active Server Pages, 
data from a database (described in detail below) can be assembled and the best 
presentation form can be selected on-the-fly. The web server preferably delivers data 

15 to the client in HTTP-, HTML-, and XML-compliant formats. 

The use of Dynamic HTML allows web pages to change and interact with the user 
without requiring the user to navigate to a new page. This makes the CareCentral 
application continuously usable as part of a user's ordinary work day. XML is used 

20 for its capabilities for describing richly-structured data such that it can be processed by 
off-the-shelf software. JAVA is used on both the client and the server. On the client 
side, invisible JAVA applets manage web page operation and presentation by 
manipulating Dynamic HTML objects. On the server, JAVA is used for generating 
web pages. The Web Presentation Layer dynamically constructs web pages based on 

25 information stored in the business objects and databases. The web browser requests a 
web page, specifying what information is needed in the web page's URL. The web 
presentation layer queries the business objects for the required information and formats 
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it as appropriate HTML or XML pages that are then sent back to the user's web 
browser. 

The application services layer preferably includes XML object services, business 
5 objects, and a reporting/integration data extractor client. The business objects 
encapsulate all of the basic knowledge about how the various entities used in the system 
of the invention operate (example entities include Patients, Users, and Care Plans). 
The business objects present a high-level view onto these entities, hiding the details of 
their representation. This ensures database consistency and simplifies the programming 
10 of operations on these entities. 

The reporting/integration data extractor client allows users to identify sets of 
interrelated data that they want to extract from the system's databases, for example 
because they want to produce a report or export the information to an external system. 
15 The data extractor client accepts the description of the data the user wants and passes 
it along to the data extraction server (described below). The server processes the query 
and returns the results to the client, which then formats the results into the form the 
user specified. 

20 The XML object services are a layer built on top of both the business objects and 
the data extractor client. The XML object services accept requests for business objects 
operations and data extraction operations expressed as XML documents. The XML 
services parse the XML request document, call on the business objects and the 
reporting extractor to perform the requested operations, and then format the operations' 

25 results as XML response and status documents that are returned to the requestor. 

The data services layer preferably includes an object/relational server and a 
reporting/integration data extractor server. The reporting/integration data extractor 
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server processes requests passed to it from the data extractor client component 
(described above). It queries the system's databases and business objects for the 
required information and passes the results back to the data extractor client for further 
formatting and presentation to the requester. The object/relational server mediates 
5 between the business objects and the relational databases that actually store the data. 
The business objects make object-oriented requests for data and data updates. The 
object/relational server maps these object-oriented requests into relational database 
queries, executes the queries, and builds and returns object structures representing the 
relational query results. Data interchange between the data services layer and the 
10 application services layer is accomplished using CORBA distributed object services. 
The use of these services allows CareCentral software components to be partitioned 
across multiple computers. This further enables efficient client-server operation and 
improves web scalability. 

15 Data is stored in databases which preferably include a Microsoft SQL Server and an 
Oracle database. Access to the data by other components of the system is 
accomplished using the ODBC/JDBC protocols, which have broad multi-vendor 
database support. 

FIG. 5 shows a block diagram illustrating the flow of data among the components 
of the system of the invention in connection with an ASP Request. At step 1, an event 
handler on an HTML page (e.g., a JavaScript function) causes an ASP request. In 
response, at step 2, the ASP scripting engine in the web server software (i.e., IIS4) 
finds the requested page and executes its server-side script. Then, at step 3, the server- 
side script code creates an instance of an EllorWSO object and calls its methods. At 
step 4, EllorWSO methods create CareCentral business objects and call their methods. 
At step 5, CareCentral business object methods interact with the CareCentral databases 
via OCP. At step 6, CareCentral business object methods return CareCentral objects 
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and other data to EllorWSO. Finally, at step 7, EllorWSO transforms those objects 
and data into a new HTML page, which is sent directly to the client browser via the 
web server software. 

5 FIG. 6 shows a block diagram illustrating the flow of data among the components 
of the system of the invention in connection with an XML request. At step 1, an event 
handler on an HTML page (e.g., a JavaScript function) calls methods of a Java class on 
the client. At step 2, one of the Java methods on the client called in step 1 expects 
XML to be returned. This method causes an ASP request. This method will wait for 

10 XML to be returned and then parse the XML and create appropriate data structures. 
At step 3, the ASP scripting engine in the web server software (e.g., IIS4) finds the 
requested page and executes its server-side script. The server-side script code, at step 
4, creates an instance of an ElloraWSO object and calls its methods. At step 5, 
ElloraWSO methods create CareCentral business objects and call their methods. At 

15 step 6, CareCentral business object methods interact with the CareCentral databases via 
OCP. At step 7, CareCentral business object methods return CareCentral objects and 
other data to ElloraWSO. At step 8, ElloraWSO creates Java objects on the server and 
calls their methods to transform CareCentral objects and data into XML. At step 9, 
XML is sent back to ElloraWSO as a result of Java method calls on the server. At step 

20 10, ElloraWSO passes the XML back to the requesting Java method on the client via 
the web server software. The requesting Java method on the client parses the XML. 
At step 11, the JavaScript function that was initiated in step 1 calls additional Java 
methods on the client for displaying the parsed XML data returned in step 10. Finally, 
at step 12, Java methods on the client transform the parsed XML into HTML, and 

25 insert it into the same HTML page that made the initial request in step 1. 
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OPEN CARE PLATFORM 

The system in accordance with the invention preferably includes middleware 
which provides a uniform method of access by client applications to different data 
5 sources. The middleware is referred to herein as the Open Care Platform, or OCP. 
The OCP middleware provides an object interface to persistent objects contained in a 
database, and simplifies defining persistent objects, creating databases that contain 
those objects, and using those objects. OCP instances each serve a different data 
source, and OCP clients can invoke multiple OCP instances to access different data 
10 sources. OCP is designed to provide access to different types of data. The OCP 
preferably supports relational databases via ODBC or other database standard. 

The OCP is based on distributed object technology and is preferably designed to 
support multiple distributed object models. The OCP can be designed to support the 
15 Object Management Group's Common Object Request Broker Architecture (CORBA) 
standard. Both SmallTalk and Visual Basic (via OLE) clients have used CORBA-based 
access to OCP. Microsoft's Distributed Common Object Model (DCOM) for client 
access via Active X may also be supported. 

20 At the highest level, developing an OCP instance for use by client applications 

involves: 

1. Developing or selecting a data source (initially Oracle and SQL Server data are 
supported); 

2. Developing a client-side OCP Application Programming Interface (API) to the 
25 specific data source; and 

3. Developing a data-source-specific, server-side OCP interface to the OCP core. 
Note that the application programmer preferably deals only with the client API. 
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The OCP instance-development process is designed so that each of steps 1-3 
above may be automated by the use of code-generation tools. For example, Oracle's 
Designer 2000 data modeling tool (with existing extensions) can be used to do all of the 
following: 
5 • design the database 

• generate the Data Definition Language (DDL) statements which 

• create the database 

• generate the Object Relational Map (ORM) file which OCP tools use to create both 
the server-side OCP interface, and the client-side OCP API. 

10 

Additional modeling tools, such as Rational Rose, may be supported. 

An OCP core is preferably provided and acts as the kernel of OCP- it does not 
change with the data source or the distributed object technology. Both client and 
15 server OCP interfaces are data source specific. 

OPENDATACONTROL fODO COMPONENT 

Since a significant purpose of components and applications in accordance with 
20 the invention is to provide a user interface to data stored in potentially a variety of data 
sources, it is advantageous to have a relatively simple method of linking a visual 
element (e.g. a Visual Basic control such as a TextBox, ListBox, OptionButton, etc.) to 
a data element. Some existing Visual Basic controls, known as bound controls, allow 
this linking through the VB Data control, but the linking must be to a specific field 
25 within a specific database. Since Ellora components and applications may not 
necessarily know the exact database name and data model of the data they will be 
displaying, it will not be possible to use bound controls and the Data control. 
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Therefore, a significant goal of the OpenDataControl (ODC) is to link together 
visual elements and data elements, allowing the data elements to come from a variety of 
data sources. In addition, ODC will also go beyond simple linking of visual elements 
to data elements to support a number of other requirements, as outlined in the next 
5 section. Due to the nature of ODC as the provider of a linkage between visual and data 
elements, it will not be responsible for any specific user interface designs or database 
models. 

As stated above, the main goal of ODC is to link together visual elements and 
10 data elements. In addition, ODC will support a number of other requirements that 
apply generically to either visual elements or data elements or both at a low level. The 
other requirements are as follows. 

1 . Support of default values 

15 

It is often the case that certain data elements in an application can have default 
values, which can save the user time when using the application. Default values may 
be simple strings or numbers that can be expressed absolutely, or they may be 
calculations that can depend upon other data elements. Therefore it would be beneficial 
20 if ODC supported assigning of default values to data elements. 

2. Support of red flags 

Certain applications may want to know when the value entered for a certain data 
element is out of a specified range, also known as a red flag. It would also be useful to 
25 have a method for visually indicating this situation. Therefore it would be beneficial if 
ODC supported red flags. 

3. Support of validation 
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Before a data element can be committed to a data source, there is almost always 
some level of validation that needs to be done on that data element. This can include 
simple validation such as validation of data type, dates and times, and it can also 
include more complex validation that requires an arbitrary function to be run to 
5 perform the validation. Therefore it would be advantageous for ODC to support 
validation. 

4. Default event routines 

Certain VB event routines may want to call ODC methods in response to user 
10 actions. It is also likely that the code for certain events for certain VB controls (e.g. 
the LostFocus event of a TextBox control) will be the same for all VB controls of that 
type. It would therefore be advantageous if ODC supported default routines for certain 
events based upon the VB control type so that most VB event routines would simply 
have to make one method call to ODC. 

15 

Objects Provided and Their Interfaces 

ODC comprises three objects, implemented as Visual Basic classes. The two 
objects that are of primary concern to the user of ODC are the Element object and the 
Elements collection object. These two objects and their relationships *are depicted FIG. 
20 7. 

An Elements object is a collection object comprising one or more Element 
objects. Conceptually, each Element object links one or more visual elements (VB 
25 controls) with one data element (attribute of some object). Instantiated Element objects 
are first programmed with the proper visual element(s), data element and behavior 
properties, and then methods of Elements collection objects and/or Element objects are 
called to perform useful work such as retrieving data from data sources, displaying data 
in controls and storing data to data sources. Each Element object must belong to an 
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Elements collection object. In other words, the Element class* Instancing property will 
be set to NotCreatable, and an Element will have to be created via the "Add" method 
of an Elements object. 

5 Since ODC is a low-level component that basically just understands linking of 

visual and data elements, there will be no support in ODC for querying a data source, 
and ODC will not understand the concept of a database session. Therefore the user of 
ODC will have to perform those functions that fall into these categories outside of 
ODC. Once a query is performed, though, certain ODC properties can be set and 
10 certain methods can be called that will operate on the results of the query. 

The third object that ODC contains is an ODC driver object. The ODC driver 
separates the logic contained in the Elements and Element objects to tie together visual 
and data elements, from the logic needed to access data via OCP (or potentially another 
15 data access mechanism). In other words, the ODC driver encapsulates all OCP calls 
made by ODC so that neither the Elements or Element objects have to make any calls 
directly to OCP. ODC supplies two generic ODC drivers, ODCDCPDriver and 
ODCOCPDriver. The ODC driver's relation to ODC Elements is depicted in FIG. 8. 

20 The flexibility inherent in using a driver allows ODC Elements to potentially 

access any data source in the same manner without knowing the details of how to 
access that data source. This can be accomplished by replacing a generic ODC driver 
with another ODC driver that implements the details of accessing another data source. 
As long as the new ODC driver has the same interface as the published generic ODC 

25 Driver interface, described in Section 3.3, ODC can use it. (Note that the same 
interface does not necessarily imply identical, but at least compatible). The ODC 
driver to be used by ODC Elements is programmed via the ODCDriver property. 
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Element Object 

The Element object is the primary object around which the design of ODC 
revolves. The primary goal of an Element object is to tie together one or more VB 
controls and one piece of data. In general, an Element is instantiated for each control 
5 on a VB form, via the Elements collection object (see next section) and then its 
properties are set. Once the Element has been instantiated and initialized, its methods 
are called to load its value into its control, get and put its value, check if its value has 
changed, and perform other processing. 

10 An important concept surrounding the Element object is that of the 

DataSourceValue vs. the CurrentValue . Conceptually, each Element object stores two 
values per data element, the DataSourceValue, which is the value that is stored in the 
data source for that data element, and the CurrentValue, which is the value that the 
user has entered or changed for that data element, usually via the Element's VB 

15 control. (Note that they are the same when the VB control is first loaded from the data 
source.) The DataSourceValue is thus obtained directly from the appropriate data 
source, whereas the CurrentValue is usually the value of the VB control. Note that 
there may be situations where the CurrentValue cannot be stored in the VB control, 
such as when the Element does not contain a VB control, or when the VB control is not 

20 dedicated. 



Another important concept to understand is that some properties will need a 
query to be performed to be set, and others will not. The process of setting the values 
of properties that do not need a query to be set is referred to as initialization , and the 
25 process of setting the values of properties that do need a query to be set is referred to 
as binding. The main reason for making this distinction is to point out that, typically, 
initialized properties will only be set once during the life of the application (or instance 
of a specific VB Form), for example in the Form_Load event, whereas bound 
properties may have to be set at various points in the application, for example when a 
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new patient is selected, when a new view is selected, or when a new data entity is 
created. This implies that a given set of properties of an Element should only be 
initialized once, and another set can be bound many times to allow display of the same 
set of data for different entities. 

5 

Elements Object 

The Elements object is a collection object that contains a collection of Element 
objects. The only means of instantiating an Element object is via the Add method of 
the Elements object. 

10 

The main purpose of the Elements collection object is to provide properties and 
methods that allow manipulation of all Element objects in the collection, thus providing 
convenient processing for the user of ODC. In general, the Elements object property 
or method will set or return the property or method with the same name in all Element 
15 objects in the collection. This implies that many properties and methods in this 
category do not have to be called at the Elements object level, but can always instead 
be called for each individual Element in the collection. 

There -are two major exceptions to the above category of properties and 
20 methods. The first is those methods that directly manipulate the collection itself. 
These include the Count property, and the Add, Remove and Item methods, which are 
directly analogous to those properties and methods in the general VB Collection object. 
(Note that the Elements Add method does add some value to the general VB Collection 
method, such as instantiating an Element object.) 

25 

The second major exception to the above category is that the Elements object is 
the only place where methods associated with processing a grid control are located. 
The reasoning behind this is that a grid control contains multiple Element objects, each 
used as a template for a grid column, and it seems logical for those methods that affect 
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or use more than one Element object to belong in the Elements collection object. 
These methods include LoadGrid, GetGridCell, StoreGridCell and the 
UnboundReadData and UnboundWriteData standard event handlers. 

5 

USER INTERFACE OF THE PREFERRED EMBODIMENTS 

FIGS. 9-13 show screenshots illustrating the user interface in the preferred 
embodiment of the "CareCentral" software of the invention. FIG. 9 shows aspects of 
10 the user interface relevant to planning a patient's care. In particular, FIG. 9 illustrates 
the interface to functions for viewing and modifying individual care plans, adding to a 
patient's overall plan, capturing data associated with the care provided, choosing from 
a set of care templates customized for a user's care practices, and customizing the care 
templates for an individual patient. 

15 

FIG. 10 shows aspects of the user interface relevant to recording a patient's 
progress. In particular, FIG. 10 shows illustrates the interface to functions for 
recording data relevant to the care provided, updating patient care plans, and providing 
notes of patient progress. 

20 

FIG. 11 shows aspects of the user interface relevant to coordinating the work 
required to deliver patient care. In particular, FIG. 11 shows illustrates the interface to 
functions for tracking work being done, recording results of work which has been 
completed, and filtering a task list to most efficiently view work being done, and 
25 viewing work which has been completed, is overdue, or is in progress. 
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FIG. 12 shows aspects of the user interface relevant to analyzing outcomes and 
costs of care delivered. In particular, FIG. 12 illustrates the design and generation of 
various reports on clinical data collected. 



5 FIG. 13 shows a menu and icon bar useful for navigating the CareCentral 

component of the invention. 

FIGS. 14-19 show screenshots illustrating the user interface in the preferred 
embodiment of the "Customizer" software of the invention. FIGS. 14 and 15 
10 show aspects of the user interface relevant to care template customization. In 
particular, these figures show the interface for modification of template definitions. 



FIGS. 16 and 17 show aspects of the user interface relevant to care option 
customization. In particular, these figures illustrate the interface for modifying care 
15 option definitions. 

FIG. 18 shows aspects of the user interface relevant to customization of the 
definition of "associated data," i.e., data associated with care options. FIG. 19 shows 
aspects of the user interface relevant to defining custom reports. 

20 

While the invention has been particularly shown and described with reference to 
a preferred embodiment thereof, it will be understood by those skilled in the art that 
various changes in form and details may be made therein without departing from the 
spirit and scope of the invention. For example, the system may be applied to the 
25 scheduling of tasks in fields other than the provision of medical care services, such as 
the commercial real estate lending field, within the scope of the invention. 



22 



WO 00/78374 



PCT/US00/16973 



The embodiments of the invention in which an exclusive property or privilege is 
claimed are defined as follows: 

1 1. A method for managing tasks associated with the provision of medical care, 

2 comprising the steps of: 

3 providing software which receives patient information identifying at least one 

4 patient, said patient information comprising information regarding medical conditions 

5 of said at least one patient; 

6 using said software to select for said at least one patient a treatment plan template 

7 comprising a task list, said task list comprising a first set of tasks and an indication that 

8 they are scheduled for said at least one patient, and further comprising a second set of 

9 tasks and an indication that they may be scheduled for said at least one patient 
10 depending upon said at least one patient's particular medical conditions; 

U using said software to schedule tasks by applying a set of rules to said information 

12 regarding medical conditions and, when said rules are satisfied, scheduling at least one 

13 task in said second set of tasks. 

14 

15 

1 2. A method for managing tasks associated with the provision of medical care, 

2 comprising the steps of: 

3 using software to create and store a database of patient information, said 

4 database comprising, for each of a plurality of patients, at least one care option having 

5 a "yes" or a "maybe" state associated therewith and a plurality of tasks associated with 

6 said at least one care option, each task having a "yes" or a "maybe" state associated 

7 therewith. 
8 

9 

1 3. A system for managing tasks associated with the provision of medical care, 

2 comprising: 
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3 a computer system operating in accordance with software to create an activity 

4 template comprising a hierarchy of tasks distributed across multiple care plan 

5 templates, each care plan template having a plurality of care options associated 

6 therewith, each care option having a plurality of tasks associated therewith. 
7 

8 

1 4. The system according to claim 3, wherein each of said plurality of care options 

2 has a "yes," "no," or "maybe" state associated therewith. 
3 

4 

1 5. The system according to claim 3, wherein each of said plurality of tasks has a 

2 "yes," "no," or "maybe" state associated therewith. 
3 

4 

1 6. The system according to claim 4, wherein said software further comprises 

2 functionality for changing care options with a "maybe" state to a "yes" state or a "no" 

3 state based upon a patient's observed conditions. 
4 

5 

1 7. The system according to claim 5, wherein said software further comprises 

2 functionality for changing tasks with a "maybe" state to a "yes" state or a "no" state 

3 based upon a patient's observed conditions. 
4 

5 

1 8. The system according to claim 4, wherein said software further comprises 

2 functionality for automatically setting care options to a "yes" state based upon a 

3 patient's observed conditions. 

4 

5 
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1 9. The system according to claim 5, wherein said software further comprises 

2 functionality for automatically setting tasks to a "yes" state based upon a patient's 

3 observed conditions. 

4 

5 

1 10. A system for scheduling tasks, comprising: 

2 a computer system operating in accordance with software to provide a 

3 questionnaire over a network to geographically distributed participants, said 

4 questionnaire including a first question and a second question displayed in response to 

5 an answer given by a participant to said first question, said software further comprising 

6 functionality for scheduling tasks to be completed based upon a plurality of answers 

7 received in response to at least said first and second questions. 
8 

9 

1 11. The system for scheduling tasks in accordance with claim 10, wherein said 

2 geographically distributed participants comprise patients and medical care providers. 
3 

4 

1 12. The system for scheduling tasks in accordance with claim 10, wherein said 

2 network comprises the internet and wherein said computer system provides said 

3 computer system provides said questionnaire via HTML pages. 

4 

5 
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